Skip to content

Conversation

ms-hujia
Copy link

This PR aims to remove the lock used in SysFsAccessInterface. The lock is not necessary and should be avoided based on below facts:

  1. Simultaneous read/write operations against the same sysfs instance are atomic by design.
  2. For simultaneous read/write operations to different sysfs instances belonging to the same device, it's the driver's responsibility to ensure the data consistency. If a lock is needed at user-level, this usually indicates defect at device driver.
  3. According to the spec of Level Zero, most get/set function has the note The implementation of this function should be lock-free..

@bellekal
Copy link
Contributor

According to the spec of Level Zero, most get/set function has the note The implementation of this function should be lock-free..
Yes, It is recommended to have the implementation lock-free and not a mandatory requirement. Please refer to Terminology.

Can you please let us know actual requirement/issue so that, We will try to support.


template <typename T>
ze_result_t FsAccessInterface::readValue(const std::string file, T &val) {
auto lock = this->obtainMutex();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Intention of having lock here is not for handling race conditions for sysfs file reads, But to ensure correct operations with FdCacheInterface (Which ensures quicker reads by avoiding redundant file open and file close operations when multiple reads are requested). Adding lock here ensures fd is not closed before read is completed in multi thread environment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants